<HTML>
<BODY>
SSFNet classes supporting model component addressing and automatic
IP address allocation for networks and host/router interfaces.

<P>SSFNET supports multiple addressing and numbering schemes for networks,
hosts/routers, and their interfaces.

<P>The <CODE>SSF.Net.Util.cidrBlock</CODE> class implements NHI, CIDR block, IP, and AS addressing,
and provides convenience methods to translate among these addressing styles.

<P><TABLE>
<TR><TH BGCOLOR="#e8e8e8" ALIGN=LEFT>
<P><FONT FACE="helvetica" color="red"  SIZE=4><B>Topological NHI addressing of Nets, Hosts, Interfaces <TT>n:n:n:h(i)</TT></B></FONT></P></TH></TR>
<TR><TD BGCOLOR=white>
<P>The basis of all addressing schemes is network topology, and in SSFNet,
NHI (Net, Host, Interface) strings are the basic notation for
identifying nodes and edges in the network graph.</P>

<P>Each Net, Host, Router, and NIC must either specify an integer ID (the
<TT>id</TT>
attribute) or an integer ID range (the <TT>idrange</TT> attribute).
At a given level (e.g., within a given Net) the IDs and ID ranges of
sub-Nets may not  overlap; they need not be compact, however.
The same is true of Hosts and Routers, and of NICs.</P>

<P>The global NHI address of a network is created by concatenating the ID
of  each network from the outermost to the innermost, separated by colons
(":").
Similarly, the global NHI address of a host or router is created by
concatenating the global NHI address of its containing network with the
Host ID, separated by a colon.  Finally, the NHI address of a NIC is
created by adding the NIC ID, in parenthesis, to the containing Host NIC
address.</P>

<P>For example, in this nested Net:</P>
<P>
<TABLE WIDTH=100% ALIGN=CENTER BORDER=1 CELLSPACING=0 CELLPADDING=10 BGCOLOR="white">
<TR><TD VALIGN=TOP>
<PRE>
 Net [ id 3
   Net [id 7
    Net [id 8
      Host [id 9 ...
            interface [id 2]
      ]
    ]
   ]
  ]
</PRE>
</TD></TR>
</TABLE>
</P>
<P>The outmost Net has NHI address <TT>3</TT>, the next Net has address <TT>3:7</TT>,
and the innermost Net has address <TT>3:7:8</TT>.  The Host has NHI address
<TT>3:7:8:9</TT>, and the interface has NHI address <TT>3:7:8:9(2)</TT>.</P>

<P>NHI numbers are specified by the modeler's use of ID
attributes. The ids have integer values that need not be
sequentially assigned, although it is strongly recommended. The component
<TT>link</TT> does not have the id attribute.
The IDs are never automatically generated; omitting an <TT>id</TT> or <TT>idrange</TT>
attribute at any level other than the topmost level is an error.  As per
the Net schema, the root Net should not have an id, idrange, or cidr
address specified; only imported Nets acquire these.</P>


<P>The id attributes for Nets and for hosts and routers belong to the same
address space, thus should be all distinct.</P>

<P>Within each host or router instance the <CODE>interface.id</CODE> integer values uniquely
identify network interfaces.</P>

<P>The above definitions of <CODE>id</CODE> attributes permit to compose bigger networks
from instances of Net without the need to re-number their internal components'
ids.</P>

<P>Note that when a Net is included in another Net, each of its NHI identifiers
simply acquires one more N: at the front of the <CODE>N:N:...:N:H(I)</CODE> string,
when it is addressed from the importing Net. More examples:</P>

<P><B>Example 1:</B> in the simplest case of a Net containing only hosts, routers and
  links, use H(I) only, e.g. <CODE>33(2)</CODE> for host 33, interface 2.</P>

<P><B>Example 2:</B> if a Net contains two Nets numbered 1, 2, then interface 1
  on host 7 in Net 1 is <CODE>1:7(1)</CODE>, and interface 1 on host 7 in Net 2 is
  <CODE>2:7(1)</CODE>.  The corresponding hosts are <CODE>1:7</CODE> and <CODE>2:7</CODE>, respectively.

<P><B>Example 3:</B> If Net 1 in Example 2 is further composed of Nets numbered 1,2,3,4,
  then an interface belonging to lowest level Net 4 could be identified
  in the master Net as <CODE>1:4:98(12)</CODE>, or in words: interface 12 of router 98
  in Net 4 in Net 1".
</TD></TR>

<TR><TH BGCOLOR="#e8e8e8" ALIGN=LEFT>
<P><FONT FACE="helvetica" color="red" SIZE=4><B>CIDR hierarchy addressing <TT>i/j/k/l</TT></B></FONT></P></TH></TR>
<TR><TD BGCOLOR=white>
<P>Each Link and Net (other than the root (toplevel)  Net) in a DML model has associated with it a
CIDR  block address, consisting of 1 or more integers separated by slashes ("/").
If <CODE>cidr</CODE> attributes are entirely omitted, they will be automatically computed
by SSF.Net.Net as follows: links and Nets are assigned CIDR block addresses relative to that
of the Net in which they are defined, starting from CIDR block zero.</P>

<P>Simply speaking, <CODE>cidr</CODE> attributes specify a logical tree of subblocks of the toplevel IP address
block allocated to a model. The values of <CODE>cidr</CODE> attributes are slash-separated integers
 similarly to a UNIX directory tree, and thus
manually specified CIDR addresses may be multilevel: e.g.,
<TT>link [ cidr 1/2/4 ...] </TT> means "this network link shall get IP addresses from block 4 in block 2 in block 1".
No two Nets or links may manually specify the same CIDR address; this is
flagged as an error.  In general, modelers should defer to the framework
for automatic CIDR assignment unless they know what they're doing: It is
easy to make errors,
and that feature should be used with caution. The manually assigned CIDR attributes
are not checked for consistency in SSFNet 1.x.</P>

<P>Read about <A HREF="http://www.ssfnet.org/InternetDocs/ssfnetTutorial-1-vlsm.html">Variable Length Subnet Mask
IP address assignment</A>,
and see an example in a
<A HREF="http://www.ssfnet.org/InternetDocs/ssfnetTutorialExample-1.html"> mini-tutorial on <TT>cidr</TT>
attributes in DML networks</A>.</P>
</TD></TR>

<TR><TH BGCOLOR="#e8e8e8" ALIGN=LEFT>
<P><FONT FACE="helvetica" color="red" SIZE=4><B>IP addressing <TT>a.b.c.d/p</TT></B></FONT></P></TH></TR>
<TR><TD BGCOLOR=white>
<P> The SSFNet version 1.x supports Variable Length Subnet Mask  (VLSM) IP address
assignement method. The IP addresses may be allocated in either of
three mutually exclusive ways:
<BLOCKQUOTE>
 <P>Manually, using attributes <TT>Net.ip</TT>, <TT>Net.link.ip</TT>
 and <TT>Net.host.interface.ip, Net.router.interface.ip</TT>.
 Use with caution, as manually assigned IP addresses are not verified for
 consistency in this release.</P>

 <P>Using the optional attributes <CODE>Net.cidr</CODE> and
 <CODE>Net.link.cidr</CODE>
 to guide the IP address assignement algorithm implemented in package SSF.Net.</P>

 <P>Fully automatically if neither <CODE>cidr</CODE> nor <CODE>ip</CODE>
 attributes are provided.</P>
</BLOCKQUOTE>
</TD></TR>

<TR><TH BGCOLOR="#e8e8e8" ALIGN=LEFT>
<P><FONT FACE="helvetica" color="red" SIZE=4><B>Autonomous Systems numbers</B></FONT></P></TH></TR>
<TR><TD BGCOLOR=white>
<P><CODE>Net.AS_status</CODE>
<P>While not a full addressing scheme, SSFNet supports the automatic
assignment of identifier numbers to autonomous systems. An included Net that specifies
the <CODE>AS_status boundary</CODE> attribute specifies that it is the enclosing Net of an autonomous
system, and is assigned the next free autonomous system number, starting from
one.  It's an error to specify that a Net is the root of an autonomous system
if it is contained within another Net that is the root of an autonomous
system.</P>
</TD></TR>

<TR><TH BGCOLOR="#e8e8e8" ALIGN=LEFT>
<P><FONT FACE="helvetica" color="red" SIZE=4><B>SSFNet 1.x implementation of addressing</B></FONT></P></TH></TR>
<TR><TD BGCOLOR=white>

<P>Currently the logic of SSF.Net is as follows: if you omit <TT>cidr</TT> attributes,
it makes default <TT>cidr</TT> blocks automatically;
if you omit <TT>ip</TT> attributes, it uses <TT>cidr</TT> (provided or computed)
to make <TT>ip</TT>;
if you supply <TT>ip</TT>, it ignores <TT>cidr</TT> if also provided. </P>
</TD></TR></TABLE>
</BODY>
</HTML>
